Good job 👍

While reading through the code I was thinking about maybe we should make this it's own action definition, e.g. digitallyinduced/test-ihp-app. Then the yaml definition would be similiar to:

# ...
jobs:
  tests:
    name: Run Tests
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: digitallyinduced/test-ihp-app

This way we could make updates to the github action later on easily without users manually neeeding to update this boilerplate file.

There's some docs here https://docs.github.com/en/actions/creating-actions/creating-a-docker-container-action I also found it interetsing to peak in https://github.com/cachix/install-nix-action and see how it's implemented (basically an action.yaml + a shell script)

@AronNovak ☝️

I started to restructure it in https://github.com/AronNovak/test-ihp-app, I'll follow-up here when we have something usable there.

https://github.com/AronNovak/test-ihp-app works locally, but to make it a really usable custom action, I think we need to make it customizable.

Docker-based GitHub actions mounts the working directory to the container, we have access to the project files.
To be able to workaround problems like digitallyinduced/ihp#1728 , or others in the future, the entrypoint.sh should allow some flexibility.

Here's my current suggestion:
https://github.com/AronNovak/test-ihp-app/pull/1/files - have an input for the GH Action, that can override the default test command, it might purge node.js from the to-be-installed set of packages, or it can do any kind of tweaks beforehand.

Does it sound good?

that can override the default test command

How about instead of overriding, you can prepend commands?

@amitaibu I restructured like that, but it seems we even don't need that, those manipulations in our case can be standalone commands inside the repo's actions YAML